<?php
/**
 * <https://y.st./>
 * Copyright © 2017 //y.st. <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => $a['XML'],
	'<{subtitle}>' => 'Extensible Markup Language',
	'<{copyright year}>' => '2017',
	'<{body}>' => <<<END
<h2>Cleaner than $a[HTML]</h2>
<p>
	$a[XML]&apos;s greatest strength is that unlike $a[HTML], it must be valid to be rendered.
	Rendering malformed files by default isn&apos;t the best idea.
	With $a[XML], when you check out how your code looks, you can immediately see when your code&apos;s malformed so you can fix it.
	In $a[HTML], such errors are often glossed over by the Web browser so you don&apos;t even see them.
	Before the $a[WHATWG] formed and got involved, there was another important reason to use $a[XML] as well: mobile clients.
	Fixing malformed markup in order to render it takes electrical power and processing power, both things that are in shorter supply on mobile clients.
	Had the Web moved forward with $a[XHTML]2 and $a[HTML] been discontinued, mobile clients wouldn&apos;t have to have been made to interpret bad markup.
	They could rely on markup to be clean, and if it wasn&apos;t, they could display the same error message that would be displayed on a desktop client.
	Thanks to the $a[WHATWG] though, $a[HTML] is continuing forward, despite its glaring flaws, and mobile clients will likely always spend their limited resources on cleaning up broken pages internally before rendering them.
</p>
<h2>Escape your code properly</h2>
<p>
	Please don&apos;t be a lazy bastard.
	Don&apos;t use <code>&lt;![CDATA[</code> <code>]]&gt;</code> in your code.
	There are exactly zero cases in which this construct is needed.
	All that this construct does is allow you to be lazy and neglect to escape your <code>&lt;</code>, <code>&gt;</code>, and <code>&amp;</code> characters.
	I&apos;m not entirely certain, but it&apos;s possible that it also functions in some cases in which <code>&quot;</code> or <code>&apos;</code> could need to be escaped.
	However, you should strive to write clean code.
	Simply escape your characters properly, and you won&apos;t have any issues.
	Escaping your characters properly even works within <code>&lt;script/&gt;</code> and <code>&lt;style/&gt;</code> tags; it doesn&apos;t interfere with the interpretation of JavaScript or $a[CSS].
	That said, you shouldn&apos;t have JavaScript or $a[CSS] in the same file as your $a[XHTML] in most cases.
	In all but a few corner cases, JavaScript and $a[CSS] should be stored in external files and linked to by the $a[XHTML] file.
</p>
<h2>Criticism of $a[XML]</h2>
<p>
	Most of the criticism that I hear about $a[XML] falls into one of three categories.
</p>
<h3>$a[HTML] allows broken code</h3>
<p>
	It used to be that when an $a[HTML] page was malformed, Web browsers wouldn&apos;t be able to render it.
	This was like any other file; when it&apos;s malformed, it doesn&apos;t make any sense to the renderer.
	However, back when competition between Web browser vendors was more fierce, Web browser venders started adding the ability to render malformed markup.
	In this way, Web developers that used those Web browsers wouldn&apos;t notice mistakes in their code, so those mistakes didn&apos;t get fixed.
	Other Web browsers that hadn&apos;t yet added the ability to render malformed documents weren&apos;t able to display these pages, and users blamed the Web browsers that conformed to the standard instead of those that had caused it: the Web browsers that <strong>*didn&apos;t*</strong> conform to the standard.
	The rendering of invalid $a[HTML] is a horrid artifact of a past war between software developers.
	It&apos;s not a good thing, but a blemish on the entire Web.
	If you try using the $a[W3C] validator on most Web pages, you&apos;ll find that even those developed by the most professional of companies often aren&apos;t even valid pages.
	Being able to see your page break and know to fix it is a <strong>*very good thing*</strong>, which is a big part of why we need $a[XML].
</p>
<h3>$a[HTML] allows missing tags</h3>
<p>
	Some people claim that omitting close tags is somehow cleaner because it&apos;s less verbose in some cases.
	$a[HTML]5 allows that practice in many cases.
	However, is that really cleaner?
	You&apos;re not telling the parser where your element stops.
	Instead, you&apos;re relying on the parser to end your element when another begins or when it finds itself unable to continue the element for some reason, such as when the container element ends.
	Omitting useful information isn&apos;t the way to write clean code.
	Leaving out closing tags is about as clean as leaving out closing parentheses.
</p>
<blockquote>
	<p>
		Does this look very clean to you?
		(It&apos;s shorter, but that doesn&apos;t make it cleaner.
	</p>
</blockquote>
<p>
	As a side note, $a[XML] also has a neat feature in which single tags look different than open tags.
	You might not find that useful if you know all of the tags available in your markup language, but often times, you know the subset of tags that you actually use or that you use most often.
	When looking at $a[XML], you know when a tag you don&apos;t recognize is open or is a single tag with no close tag.
	You can even self-close empty tags.
	For example, I write <code>&lt;script src=&quot;/script/javascript.js&quot; /&gt;</code> instead of <code>&lt;script src=&quot;/script/javascript.js&quot;&gt;&lt;/script&gt;</code>.
	In $a[HTML], there&apos;s no way to condense this, and you must always specify a close tag even when it makes no sense for the element to even be open.
	Otherwise, the entire rest of the page might be interpreted as malformed JavaScript instead of as $a[HTML].
</p>
<h3>$a[JSON] (or something else) is better for storing data</h3>
<p>
	$a[XML] isn&apos;t a data-storage format.
	It&apos;s a document markup format. It&apos;s Extensible Markup Language, after all, not Extensible Data-Storage Language.
	If you misuse a tool, sure, you&apos;ll get poor performance out of it.
	For example, if you store textual information as a $a[PNG] file and claim that that&apos;s what $a[PNG] files are for, it&apos;s going to make the $a[PNG] format look bad.
	$a[PNG] files are absolutely horrid for storing textual information.
	However, they excel at storing non-photographic graphic art.
	The same applies to $a[XML].
	If you try to use $a[XML] as a data-storage format, you&apos;re going to get suboptimal results.
	If you&apos;re storing data, yes, $a[JSON] is the better format!
	However, it&apos;s not because $a[JSON] is actually a better format than $a[XML] at all.
	It&apos;s because $a[JSON]&apos;s strength is data storage while $a[XML]&apos;s strength is instead document markup.
</p>
<h4>$a[XML] for data storage</h4>
<p>
	As I said, $a[XML] is a markup language, not a data-storage language.
	However, it can still be used effectively for data storage when used correctly.
	Much of the problem when developing an $a[XML] flavor for data storage that makes it inefficient is caused by people doing it wrong.
	Again, this isn&apos;t the fault of $a[XML] and doesn&apos;t mean that $a[XML] itself isn&apos;t good for what it&apos;s good at.
	Instead of having an element for each key/value pair, it&apos;s often more efficient to instead use attributes of a single element.
	According to Wikipedia, doing that <a href="https://en.wikipedia.org./wiki/JSON#XML">results in file sizes that are just as small or only slightly larger than those achieved in $a[JSON]</a>.
	Even when $a[XML] is the wrong tool for the job, it does pretty well when used with a little skill.
	Now that&apos;s impressive!
	Additionally, in $a[XML], you can see what element is ending when it ends.
	In $a[JSON], you can&apos;t do that.
	Instead, you have to count your layered braces to find the start of the nested element to know what element it is.
	Proper indention of course helps with this, but it helps in $a[XML] too.
</p>
END
);
